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We claim: 



1. In a multitaskinc operating system that uses virtual memory to share 
physical memory among concun^ently executing application programs, a method for 
controlling allocation of physical memory comprising: 

in response to a call from anVpplication program to group specified code or 
data in a group, creating a structure toVroup the code or data specified by the 
application; \ 

monitoring for a not-present internsmt generated in response to request to 
access any part of the code or data in the group; 

when the not-present interrupt occurs ibr a unit of memory in the group, 
loading all of the code or data in the group that ik not already in physical memory into 
physical memory from secondary storage at one time, including loading the imit of 
memory for which the not present interrupt has occmred and all other units of memory 
used to store the code or data in the group. \ 

2. 'rafemethod of claim 1 wherein the structure includes a linked list 
structure that links together code or data stored at non-contiguous portions of virtual 
memory. \ 

3. The method of claim 2 wherein the structure links pages of memory 
associated with the non-coiWuous portions of code or data. 

4. The method of claim 1 further including: 

repeating the steps of claim>l for additional groups of code or data specified by 
the application. \ 

5. The method of claim 4 fiMier including: 

repeating the steps of claim 1 for a group of code or data for another 
concurrently executing application such that more than one concurrently executing 
application program has specified at least one group of code or data to be treated as a 
single piece of memory for loading into physical m^ory in response to a not-present 
interrupt. \ 
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6. The method of claim 1 further including: 

when the not^present interrupt occurs, checking whether the interrupt has 
occurred for a unit of memory in the group by evaluating whether an address of the 
memory request for whicri the interrupt occurred is within a series of non-contiguous 
5 memory addresses of the gnoup. 

7. The method o^laim 1 further including: 

tracking memory accesses to units of memory in the group together such that 
when a unit of memory in the group is accessed, all of the units of memory in the 
group are marked as accessed; and^ 
10 determining which portions hf physical memory to swap from physical 

memory to secondary storage by deteWining which units of code are marked as 
y accessed, such that units are selected ta be swapped from physical memory to 

111 secondary storage based on frequency o^use or how recently the units of code have 

If, been accessed. 

bJ 15 8. The method of claim 7 further including: 

]^ in response to a call from an application program to group specified code or 

data in a second group, creating a second structure to group the code or data specified 
by the application; 

I ^ tracking memory accesses to units of mitmory in the first and second group 

i3 20 such that when a unit of memory in both the firsA and second group is accessed, all of 

the units of memory in the first and second groupWe marked as accessed and the unit 
of memory in both the first and second group is me^ked as being accessed twice. 

9. The method of claim 8 

when a block of code or data shared between t^o or more groups is accessed, 
25 marking the block as being accessed n times where n is\he number of groups that 
share the block. 

10. A computer-readable medium storing instnl^tions for performing the 
steps of claim 1. 

11. In a multitasking opiating system that uses virtual memory to share 
30 physical memory among concurrentlys^futing application programs, a virtual 

memory management system comprBs 
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a physiral memory manager for swapping code and data between secondary 
storage and phyacal memory to enable applications to share physical memory and for 
loading xmits of memory from secondary storage to physical memory; 

an API modme for grouping portions of code or data in a group in response to 
5 a function call from ala application program that designates portions of the code or data 
to be put in the group; Jmd 

a memory monitor in communication with the physical memory manager and 
the API module, the memory monitor operable to monitor a processor for a not-present 
interrupt, and operable to inw)ke the physical memory manager to load in all portions 
10 of the group not already in physical memory when the processor generates a not- 
present interrupt in response to £^emory request directed to any code or data in the 
^3 group. 

In 12. The virtual mtmofy rdanigement system of claim 11 wherein the 

•r: memory monitor is operable to tlack accesses to units of memory in a group 

I J 15 and is operable to mark all units of memo^ as accessed when any one of the units of 

Iz memory in a group is accessed. 

5 13. The virtual memory managem^t system of claim 11 wherein the 

Ifi memory monitor is operable to track memory ao^sses to blocks of memory that are 

' ^ shared among more than one group and is operablevto mark all units of memory in a 

20 shared block n times when any one of the units of memory in the shared block is 



accessed, where n is the number of groups that include Ihe shared block. 

14. The virtual memory manager of claim 11 wherein the physical memory 
manager is operable to monitor memory accesses to units ofinemory and is operable 
to swap units of memory from physical memory to secondary storage when necessary 

25 to satisfy a request for a piece of code or data that is not present ill physical memory. 

15. The virtual memory manager of claim 14 wherein tti^^units of memory 
are pages. 
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16. The virtual mMiory manager of claim 14 wherein the physical memory 
manager marks a unit of mem&ry as used in response to a memory request for the unit; 
wherein the physical memory manager marks all units of memory in a group as used 
whenever a unit of memory in tne group is accessed, and wherein the physical memory 
manager selects which of the imik to swap from physical memory to secondary 
storage to satisfy a memory reques^t for physical memory by determining which unit or 
units are least recently used. 

17. The virtual memon^ njmiager of claim 11 wherein the API module is 
responsive to concurrently execihin^Jtoplication programs and is operable to maintain 

10 data structures representing groups of cbde or data for more than one application 
program to be loaded into physical memory together in response to a not-present 
interrupt for a unit of memory that residesVn one or more of the groups. 

18. The virtual memory managed of claim 11 wherein the API module is 
operable to enable the application program t^add or delete code or data from the 

15 group dynamically, at run time. 

19. The virtual memory manager of idaim 18 wherein the API module is 
operable to create and dynamically update a data istructure maintaining a list of 
memory blocks included in the group based on reqipests by the application to create the 
group and change the code or data in the group, 

20. A computer^eadable medium having stored thereon a data structure 
comprising: 

a series of data fields repr^enting blocks of code or data associated with an 
application to be treated as a single umt for purposes of virtual memory management, 
the data fields including a list of memorj^ addresses of the blocks and sizes of each 
25 block in the list; 

wherein the data structure is evaluate in a data processing operation to load 
each of the blocks into physical memory whenfever a not-present interrupt is generated 
for any memory address referring to a location in^^luded in one of the blocks. 




